Skip to content

λPrize 0018#75

Draft
weboko wants to merge 1 commit into
masterfrom
weboko/lp-0018
Draft

λPrize 0018#75
weboko wants to merge 1 commit into
masterfrom
weboko/lp-0018

Conversation

@weboko

@weboko weboko commented Jun 3, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

@github-actions

github-actions Bot commented Jun 3, 2026

Copy link
Copy Markdown

✅ Validation passed

A reviewer will assess against the prize criteria.
ℹ️ No prize-related changes; skipping submission checks.


Automated check. See solution template and TERMS.

@fryorcraken fryorcraken left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Would bne good to liaise with @jm-clius or @moudyellaz see if any of the "identity stack" plans would be useful here. Meaning should we wait for them to deliver first, or shoudl we publish LP as is.

I would rewrite the usability to make the UI clearer. Eg, I assume the flow is I can share doc xyz to Alice's account (a public or private LEZ account), and alice would "automatically" receive it?

This is also in line with the idea of "deal room" that we want to see.

Comment thread prizes/LP-0018.md

## Overview

This prize funds a **customer-owned, reusable encrypted document vault** for KYC/KYB and sensitive corporate documents, built end-to-end on the Logos stack with no centralised server. A customer — a **person or a company** — uploads sensitive documents **once** (passport, proof of address, certificate of incorporation, UBO and shareholder documents, board/shareholder resolutions, tax and onboarding documents), stores them **encrypted** in Logos Storage, and later grants a specific recipient — a bank, an exchange, a lawyer — **time-boxed access to selected files or packages**. When the relationship ends, the customer **revokes future access**. No document, and no sensitive metadata, ever leaves the customer's control in the clear.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the relationship ends, the customer revokes future access. No document, and no sensitive metadata, ever leaves the customer's control in the clear.

Not really possible in the digital world, one can always do a local copy when they have access.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably bad formulation with ever leaves the customer's control
the idea is about revoking only future access revokes future access

@jm-clius

Copy link
Copy Markdown

It does seem like the Identity track would be useful here, although in terms of roadmap we only plan to have minimal Identity for mainnet.

It will entail (by end of Q3):

  • create a "λAccount" - basically just a registered long-lived identifier that serves as ID key for a "container"
  • the "container" can be looked up in a registry (on-chain) and contains one or more keys associated with the identity. These keys can be added or revoked by authorised owner of the λAccount

See summary here

Associated external identifiers (e.g. associating wallets, etc.) is only for post-mainnet.

I didn't read in detail, but looking at this prize it seems as if a change from wallet-owned vault to λAccount-owned vault in future, shouldn't be too extensive. Given our timelines/priorities, though, I think it will at least be until September before there are useful identity library/primitives for you to use.

@weboko

weboko commented Jun 17, 2026

Copy link
Copy Markdown
Collaborator Author

thanks @jm-clius ! so, looks like we can proceed with wallet based identity for the time being

@fryorcraken are you fine with proceeding with this as LP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants